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1.  Introduction 


Communications,  Electronics,  Research,  Development,  and  Engineering  Center  (CERDEC’s) 
Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and 
Reconnaissance  On-the-Move  (C4ISR  OTM)  Testbed  and  associated  experimentation  began  in 
2001  at  the  direction  of  Dr.  A.  Michael  Andrews,  then  the  Office  of  the  Assistant  Secretary  of 
the  Army  for  Acquisition,  Logistics,  and  Technology’s  Deputy  Assistant  Secretary  for  Research 
and  Technology  with  the  creation  of  a  Special  Projects  Office  to  support  the  demonstration  and 
evaluation  of  C4ISR  technologies  for  Future  Combat  Systems  (FCSs).  The  2007  experiment 
employed  over  100  different  sensor,  command  and  control,  and  communications  systems 
augmented  with  a  simulated  Brigade-sized  element  (7).  In  this  report  we  describe  how  the  Anny 
Research  Laboratory  (ARL)  and  CERDEC  integrated  unmanned  ground  vehicles  (UGVs),  a 
variety  of  unattended  ground  sensors  (UGSs),  and  a  micro  air  vehicles  (MAVs)  into  the 
experiment  and  exercise.  This  report  focuses  on  the  systems,  subsystems,  and  components 
relevant  to  ARL’s  integration  efforts. 

ARL  brought  several  UGVs,  a  MAV,  and  both  operational  and  experimental  UGSs  to  the 
experiment.  UGS  communications  was  provided  by  an  ad-hoc  network  of  ARL-developed 
“Blue  Radios”.  Communications  for  the  UGVs,  operator  control  units  (OCUs),  and  MAV 
ground  station  was  provided  by  a  mobile  ad-hoc  network  (MANET)  running  on  top  of  802. 1  lg. 
Communications  from  the  UGSs  and  UGVs  were  routed  to  a  High  Mobility  Multipurpose 
Wheeled  Vehicle  (HMMWV)  serving  as  a  communications  gateway  to  the  Soldier-Level 
Integrated  Communications  Environment  (SLICE)  Soldier  Radio  Wavefonn  (SRW)  radios 
providing  vehicle-to-vehicle  communications.  Further  processing  and  fusion  of  the  UGS,  UGV, 
and  MAV  data  was  performed  on  this  gateway  HMMWV.  The  results  were  handed  off  to 
CERDEC-developed  software,  the  C4ISR  Information  Management  Service  (CIMS),  which 
routed  the  information  to  other  vehicles  over  SRW  and  to  the  network  operations  center/tactical 
operations  center  via  Warfighter  Information  Network-Tactical  (WIN-T).  Ultimately  the 
information  was  displayed  using  a  CERDEC-enhanced  version  of  the  Force  XXI  Battle 
Command,  Brigade-and -Below  (FBCB2)  mapping  system.  Figure  1  provides  a  simplified, 
conceptual  view  of  the  communications  links  and  deployment  of  various  assets  involved  in  the 
integration. 
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Figure  1.  Simplified  conceptual  deployment  of  ARL  assets  in  C41SR  OTM. 


This  report  is  organized  as  follows.  First  we  describe  the  ARL  software  infrastructure  and  its 
integration  into  the  SRW  network  and  FBCB2.  Next  we  describe  the  integration  of  the  UGSs 
and  associated  software.  The  third  section  describes  the  UGVs  and  their  integration  and 
associated  software.  The  fourth  section  describes  the  MAV  integration.  Instead  of  identifying 
future  work  in  a  separate  section,  each  section  contains  its  own  future  work  sub-section. 


2.  Software  Infrastructure 

2.1  The  Agile  Computing  Middleware 

2.1.1  The  Existing  System 

ARL  began  developing  middleware  during  the  mid-1980s  to  mediate  between  applications  and 
heterogeneous  communication  services.  While  Internet  Protocol  (IP)  had  been  adopted  and 
standardized  by  that  time,  there  were  (and  still  are)  a  number  of  devices  using  a  variety  of  other 
communication  protocols.  Many  of  these  protocols  are  standards-based,  but  others  remain 
proprietary.  ARL  adopted  a  middleware  approach  to  isolating  and  protecting  applications  from 
changes  in  the  underlying  communications  infrastructure.  This  middleware  provided  a  layer  of 
abstraction  which  allowed  the  applications  to  communicate  seamlessly  and  transparently  across  a 
variety  of  devices,  from  experimental  to  operational,  in-house  and  externally  developed.  With 
the  award  of  the  Advanced  Decision  Architectures  Collaborative  Technology  Alliance  in  2001, 
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ARL  established  a  fruitful  and  ongoing  collaboration  with  a  group  of  researchers  at  the  Institute 
for  Human  and  Machine  Cognition  (IHMC)  who  shared  a  similar  view  of  the  benefits  of 
middleware  mediation.  We  began  to  explore  the  possibility  of  extending  ARL’s  middleware  to 
provide  additional  capabilities  not  readily  available  from  the  communications  infrastructure. 
These  additional  capabilities  focused  on  the  opportunistic  discovery  and  exploitation  of  available 
resources  to  improve  capability,  performance,  efficiency,  fault  tolerance,  and  survivability. 

IHMC  coined  the  term  Agile  Computing  Middleware  (ACM)  (2)  to  emphasize  the  desire  to  both 
quickly  react  to  changes  in  the  environment  and  exploit  transient  resources  which  may  only  be 
available  for  brief  periods.  ARL  and  IHMC  have  since  collaborated  on  the  further  development 
of  the  ACM  and  used  it  in  the  Horizontal  Fusion  Quantum  Leap,  Command  and  Control  of 
Robotic  Entities,  and  C4ISR  OTM  experiments  and  exercises.  Some  of  the  ACM  capabilities 
utilized  in  these  experiments  and  exercises  include  message-based  communication  flows  along 
the  orthogonal  dimensions  of  reliability  and  sequencing1,  message  tagging  and  replacement2,  a 
flexible  peer  to  peer  (P2P)  dissemination  and  organization  protocol,  connection  monitoring,  and 
service  discovery  permitting  the  dynamic  registration,  deregistration  and  migration  of  arbitrarily 
complex  services  with  arbitrarily  complex  signatures  and  parameters. 

In  addition,  ACM,  ARL,  and  IHMC  developed  a  cross-layer  network.  The  motivation  behind  the 
introduction  of  this  new  component  arose  as  a  result  of  the  difficulties  and  vagaries  encountered 
when  introducing  MANETs  into  various  existing  ARL  systems.  Generally,  the  introduction  of 
MANETs  has  resulted  in  a  rethinking  of  the  sanctity  of  the  OSI  seven  layer  model3.  While 
clearly  a  useful  architectural  abstraction  for  designing  scalable  solutions  via  clear  separation  of 
concerns,  the  dynamic  properties  of  MANET  environments4  are  causing  researchers  and 
developers  to  think  about  selectively  exposing  the  layers  to  allow  couplings  to  support  timing 
guarantees,  congestion  control,  quality  of  service  (QoS)  provisioning,  and  the  like.  In  a  wired 
environment,  link  bandwidth,  error  rates,  and  topology  tend  to  be  stable,  allowing  QoS  to  be 
determined  upon  the  initial  establishment  of  the  connection  with  no  need  to  modify  path 
characteristics  over  the  life  of  the  connection.  In  a  MANET  environment,  network 
characteristics  can  vary  continuously  depending  on  the  degree  of  mobility  of  each  of  the 
constituent  nodes.  In  addition  to  a  dynamic  topology,  MANETs  in  tactical  environments  must 
contend  with  a  multitude  of  noise  sources  and  active  interference,  further  increasing  error  rates 


1  Flows  can  be  selected  from  one  of  four  possible  combinations: 

1)  Rcliable/sequenced  messages  are  analogous  to  the  delivery  and  sequencing  guarantees  provided  by  TCP. 

2)  Unreliable/unsequenced  messages  are  analogous  to  UDP  datagrams. 

3)  Rcliable/unsequenced  messages  are  provided  for  applications  which  want  a  delivery  guarantee  but  don’t  care  what 
order  they  arrive  at  the  destination. 

4)  Unreliable/sequenced  messages  are  provided  for  applications  which  don’t  care  that  all  messages  are  delivered  but  do 
care  that  if  they  arrive,  they  arrive  in  the  same  order  they  were  sent  (such  as  some  of  forms  of  streaming  video). 

2 

“  To  provide  for  replacement  of  one  or  more  messages  which  have  been  queued  but  not  yet  transmitted  and  which  have 
become  obsolete  because  of  newer  information  (such  as  current  location  or  state). 

3 

ISO/IEC  7498-1:1984,  "Information  Technology  -  Open  Systems  Interconnection  -  Basic  Reference  Model  -  The  Basic 
Model”. 

4  Mobility,  energy  concerns,  spectrum/channel  sharing,  et  al. 
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and  decreasing  bandwidth.  If  distributed  systems  in  a  MANET  have  access  to  lower-layer 
network  infonnation,  they  can  be  made  more  efficient  and  resilient  by  anticipating  and  adapting 
to  changes  in  the  network  state5.  Additionally,  lower  MANET  layers  which  have  access  to 
application-level  requirements  and  constraints  can  allocate  resources  more  optimally.  The  cross¬ 
layer  substrate  provides  a  common  interface,  allowing  applications  to  both  query  and  inform 
lower  layers  in  a  consistent  manner  regardless  of  the  types  of  devices,  routing,  or  scheduling 
protocols  in  use  on  the  network. 

While  applications  which  are  individually  aware  of,  and  independently  adapt  to,  changes  in  the 
network  environment  may  result  in  more  efficient  usage  of  the  available  resources,  they  may  also 
result  in  greater  instability  (e.g.,  as  a  result  of  competing  requirements  or  greedy  strategies). 
While  nothing  prevents  applications  from  choosing  their  own  adaptation  strategy,  group 
adaptation  across  an  application’s  collective  requirements  is  likely  to  yield  better  results.  To  that 
end,  we  are  exploring  using  the  ACM  to  provide  collective  QoS  guarantees  and  dynamic 
adaptation  across  all  of  the  applications  within  a  distributed  system  in  order  to  better6  use  the 
resources  available  at  any  given  instant  from  a  more  global  perspective. 

Figure  2  illustrates  the  components  and  data  flows  within  the  middleware  and  cross-layer 
substrate.  Mockets  provides  connection  monitoring,  message  tagging  and  replacement,  and 
(un)reliable/(un)sequenced  communication  flows.  The  Group  Manager  provides  the  flexible  P2P 
dissemination  and  organization  protocol,  and  AgServe  provides  for  distributed,  dynamic  service 
(de)registration,  discovery,  and  migration.  FlexFeed  provides  intelligent  distribution  of  content 
between  nodes  through  the  use  of  en-route  message  transfonnation  and  other  techniques.  The 
other  components  illustrated  were  not  used  within  C4ISR  OTM.  More  detail  may  be  found  in  (3 
through  5).  Note  that  components  within  the  ACM  are  designed  to  work  with  or  without  the 
cross-layer  substrate.  Similarly,  applications  can  communicate  directly  with  the  cross-layer 
substrate,  the  ACM,  or  even  the  lower-level  transport  layer. 


5  An  immediate  efficiency  is  to  piggyback  application  data  on  top  of  any  control  traffic  being  generated  by  lower  layers 
anyway  for  other  purposes  (e.g.,  the  beacons  and  route  maintenance  messages  associated  with  both  proactive  and  reactive  routing 
protocols). 

6  Decisions  still  have  to  primarily  be  made  based  solely  on  local  decisions  to  minimize  communications  overhead  introduced 
by  the  coordination  itself.  So  the  concept  of  a  “globally  optimal”  solution  is  abandoned  in  favor  of  an  adequate  or  sufficient 
assigmnent  of  resources. 
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Figure  2.  Agile  computing  middleware  and  cross-layer  substrate. 


2.1.2  Future  Work,  The  ACM 

Current  efforts  in  this  area  include  determining  agility  metrics  to  quantify  the  performance  of  the 
ACM,  developing  distributed  collective  coordination  strategies,  identifying  topological  and  other 
communication  characterizations  which  can  support  this  distributed  coordination,  and  integrating 
other  communications  devices  within  the  cross-layer  substrate  (such  as  ARL’s  Blue  Radio.) 

2.2  The  Servers 

2.2.1  The  Existing  System 

The  current  system  is  based  around  four  centralized  servers,  each  managing  a  different  type  of 
data.  Producers  generate  data  and  route  it  to  the  appropriate  server  which  then  reflects  the  data 
to  all  interested  consumers.  The  four  servers  are  the  TOS,  the  SOS,  the  Multimedia  Server,  and 
the  Collaboration  Server.  This  centralized  approach  to  data  storage  and  dissemination  has 
proven  to  be  inappropriate  (if  not  infeasible)  for  a  MANET  environment  and  is  used  for 
historical  reasons.  Development  of  a  distributed  replacement  for  this  architecture  is  underway. 
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Each  server  in  the  system  advertises  its  service  type,  listen  endpoint,7  and  protocol8  via  an  ARL- 
developed  surrogate  for  the  AgServe  middleware  component  called  the  AgentRegistry  which 
internally  uses  the  GroupManager  for  distributed  dissemination.  Clients  query  the 
AgentRegistry  for  the  location  of  servers  providing  the  services  they  require.9  Clients  initially 
connect  to  the  server  using  the  listen  protocol  specified  in  the  server’s  service  advertisement. 
Clients  can  negotiate  a  protocol  change  if  the  default  listen  protocol  is  not  acceptable.  Direct 
communications  with  the  servers  can  be  transported  over  transmission  control  protocol  (TCP)  or 
user  datagram  protocol  (UDP)  using  standard  sockets,  or  over  (un)reliable/(un)sequenced 
Mockets  message  flows.  Indirect  communications  via  Web  Services  Definition  Language  web 
services  are  also  supported  via  the  introduction  of  specialized  gateway  clients  created  solely  for 
this  purpose. 

The  TOS  processes  MIL-STD-2525B-based  extensible  markup  language  (XML)  messages.  This 
server  is  used  to  disseminate  position  updates  for  every  UGS,  UGV,  MAV,  HMMWV,  and  other 
unit  in  the  system.  It  is  also  used  to  disseminate  operational  and  tactical  graphics,  enemy 
positions  and  activities,  and  any  other  information  within  the  scope  of  MIL-STD-2525B.  This 
information  is  ultimately  visualized  for  the  end  user  as  symbols  displayed  on  a  mapping  system. 

The  SOS  collects  and  disseminates  UGS  detections  and  sensings.  The  server  supports  reporting 
of  lines  of  bearing,  proximal  activity,  electronic  signatures  and  target  locations.  Messages  to  and 
from  this  server  are  fonnatted  as  XML  conforming  to  an  ARL-developed  schema.  This  server’s 
primary  purpose  is  to  provide  a  single  collection  point  for  data  fusion  applications.  It  is  also 
used  to  support  visualization  of  all  sensor  activity  and  state  as  an  engineering  or  diagnostic  aid. 

The  Multimedia  Server  stores  and  disseminates  images,  movies,  audio  reports,  and  other  large 
binary  objects.  When  multimedia  data  is  collected  by  an  UGS,  an  operator,  or  other  process,  the 
data  and  its  associated  metadata  are  pushed  to  the  server  which  stores  the  data  locally  and 
reflects  the  metadata  to  notify  other  consumers  of  the  existence  of  the  new  collect. 

The  Collaboration  Server  supports  the  tethering  of  map  displays  across  users,  the  dissemination 
of  attentional  sketches  and  other  graphical  annotations,  text  chat,  and  file  transfer.  Users  may 
collaborate  using  either  a  free-form  or  moderated  protocol.  In  free-form  groups  users  may  join, 
leave,  or  create  any  session  at  any  time;  they  may  tether  to/untether  from,  share  sketches,  send 
files,  and  chat  with  any  other  user  in  the  session  at  any  time.  In  a  moderated  session  all  of  these 
activities  must  be  approved  (at  least  initially)  by  the  moderator.  By  default,  the  moderator  is  the 
user  who  created  the  session,  but  any  user  who  later  joins  can  become  the  moderator  with  the 


7  IP  address  and  port  number. 

8  TCP.  UDP.  or  Mockets. 

9  This  query  is  typically  persistent  allowing  clients  to  request  a  server  which  is  not  yet  available,  continue  to  do 
other  processing,  and  then  connect  to  the  server  asynchronously  later  when  its  existence  is  pushed  to  them.  Via  the 
connection  monitoring  capabilities  of  the  middleware,  it  also  allows  for  servers  to  disappear  and  reappear  (for 
whatever  reasons)  with  minimal  impact  on  the  clients. 
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current  moderator’s  approval.  Moderators  can  also  force  other  users  to  tether  their  map  to 
another  user  (or  nobody),  and  to  share  their  sketches  or  not. 

None  of  these  servers  have  inherent  support  for  persistence.  Persistence  is  provided  via  special 
consumers  which  attach  to  the  servers  and  store  the  reflected  reports  in  a  database  or  other  file. 

Figure  3  shows  the  deployment  of  these  servers  and  supporting  software  within  the  C4ISR  OTM 
experiment.  The  servers  were  intentionally  deployed  on  a  vehicle  other  than  the  UGS- 
UGV/SRW  Gateway  HMMWV  to  demonstrate  that  the  ACM,  cross-layer,  and  distributed 
discovery  components  would  interoperate  seamlessly  across  different  networks. 
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UGS  Fields  UGVs/MAV 


Figure  3.  ARL  server  deployment  and  integration  w  CIMS  and  FBCB2. 


In  addition  to  the  ARL  servers  and  archiving  clients  described  above,  a  set  of  fusion  process 
collectively  known  as  Sensed  Object  Server  (SOS)-to-Tactical  Object  Server  (TOS)  receives  raw 
detections  from  the  SOS  and  sends  MIL-STD  2525B  unidentified,  unaffiliated  ground  track 
symbols  to  the  TOS  for  dissemination.  Unknown  ground  track  symbols  are  created  where 
acoustic  bearings  within  a  temporal  window  intersect  and  at  the  location  of  a  tripwire  or 
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proximity  sensor  detecting  activity.  Since  there  was  no  facility  within  FBCB2  for  displaying  raw 
sensor  activity,  these  unidentified  moving  object  symbols  cued  the  FBCB2  operators  where 
activity  was  occurring  and  which  camera  captures  should  be  examined.  To  minimize  the  amount 
of  clutter  on  ARL’s  map  display,  SOS-to-TOS  deletes  the  detection  symbols  from  the  TOS  after 
10  seconds.  FBCB2  has  its  own  decay  mechanism  that  ages  symbols  based  on  time  of  last 
report.  SOS-to-TOS  also  sends  sensor  status  reports  to  TOS  every  5  minutes  to  inform  the 
operators  of  UGS  state  and  to  prevent  FBCB2  from  aging  the  UGS  symbols  away. 


TOS-to-CIMS  and  MM-to-CIMS  attach,  respectively,  to  the  TOS  and  Multimedia  Server  as 
clients.  They  expose  a  listen  socket  on  a  predefined  port  that  the  CIMS  conduit  attaches  to. 
Received  data  is  passed  to  the  CIMS  conduit  via  the  socket.  For  tactical  symbols,  this 
communication  is  bidirectional.  The  CIMS  Conduit  uses  the  CIMS  Gateway  to  provide  reliable 
communications  over  the  SRW  SLICE  network  and  wraps  additional  user  interface  (TJI) 
elements  around  FBCB2  to  provide  network  status,  chat,  and  imagery  capabilities  via  the  CIMS 
Information  Server.  Figures  4  and  5  show  examples  of  the  CIMS-enhanced  FBCB2  display  that 
was  presented  to  the  operators. 


Imagery  Calf  ctian 


Chat  Wind* 


FBCB2 


Network  Status 


Figure  4.  CIMS  enhanced  FBCB2  showing  sensor  imagery. 
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Figure  5.  CIMS  enhanced  FBCB2  showing  text  information. 

2.2.2  Future  Work,  The  Servers 

The  major  problem  with  the  current  architecture  is  the  reliance  on  communication  with  a 
centralized  server.  Such  communication  cannot  be  guaranteed  in  the  highly  mobile, 
intennittently  connected  network  environment  typical  of  MANETs.  However,  there  are 
advantages  to  this  centralized  approach  in  more  robust  environments  like  those  provided  by 
WIN-T  and  the  global  information  grid.  Our  current  development  efforts  focus  on  removing  the 
dependencies  on  these  servers  by  relocating  them  from  the  core  to  the  periphery  of  the  system, 
where  they  will  continue  to  serve  as  gateways  to  other  systems.  To  accomplish  this,  we  plan  to 
create  specialized  P2P  groups  using  the  Group  Manager  component  in  the  ACM.  The  data 
reflection  function  currently  performed  by  the  servers  will  be  replaced  by  dissemination  through 
these  P2P  groups.  External  systems  can  continue  to  interface  with  the  ARL  system  by  sending 
and  receiving  information  using  the  current  server  interfaces,  but  the  gateway  servers  will  simply 
function  as  peers  within  the  P2P  group  and  will  no  longer  maintain  the  single,  authoritative  data 
repository. 

A  more  subtle  problem  with  the  current  architecture  is  that  the  servers  typically  maintain  a  thread 
for  each  connected  consumer  and  unicast  all  reflected  data  to  them.  This  is  clearly  inefficient 
when  most  or  all  of  the  clients  have  the  same  data  requirements.  Moving  to  the  distributed  P2P 
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approach  will  allow  us  to  gain  some  efficiencies  from  the  multicast  strategy  used  by  the  Group 
Manager.  In  situations  where  clients  have  differing  data  requirements,  an  intelligent  approach 
like  that  provided  by  FlexFeed  within  the  ACM  is  more  appropriate. 

Different  types  of  servers  will  warrant  different  P2P  strategies  and  structures.  For  supporting 
and  maintaining  situational  awareness  by  periodically  distributing  position  data  to  all  nodes  as 
efficiently  as  possible,  simple  epidemic  and  broadcast  protocols  may  suffice.  For  sensor  and 
data  fusion,  the  data  may  be  useless  if  it  isn’t  delivered  to  fusion  centers  quickly  and  efficiently. 
In  this  case,  the  fusion  centers  (and  the  communication  routes  to  them)  become  differentiated 
from  their  peers  by  virtue  of  their  importance.  For  human  collaboration,  the  peers  and  groups 
emerge  dynamically  as  a  result  of  user-to-user  interactions10  and  may  bear  little  resemblance  to 
the  underlying  network  topology.  In  these  situations  it  is  advantageous  to  dynamically  adapt  the 
dissemination  protocol  and  associated  distributed  data  structures  to  better  match  the  higher  level 
network  environment. 

2.3  The  Map  Display 

2.3.1  The  Existing  System 

The  mapping  system  ARL  used  for  this  effort  was  developed  beginning  in  2002  as  a  project  for 
the  Intelligence  and  Security  Command  (INSCOM).  The  fundamental  ideas  were  that  1)  map 
displays  can  be  tethered  to  ensure  that  collaborators  are  “on  the  same  page”,  2)  sketches  and 
other  annotations  drawn  on  the  map  can  be  shared  to  enhance  collaboration,  and  3)  laydown  of 
control  measures  and  other  tactical  graphics  specified  in  MIL-STD-2525B  can  be  facilitated  by 
allowing  users  to  draw  them  free-hand  with  a  touch  screen,  stylus,  or  mouse.  Because  of  its 
focus  on  the  use  of  free-hand  drawings  to  support  collaboration  and  intelligence  preparation  of 
the  battlefield,  this  application,  coupled  with  the  Collaboration  Server  and  supporting 
infrastructure,  became  known  as  Digital  Ink. 

Digital  Ink  is  implemented  as  an  extension  into  ESRI’s  ArcMap  application.  It  consists  of  3 
main  components:  symbology,  collaboration,  and  sensor  coverage  display.  The  symbology 
component  supports  the  free-hand  lay-down  and  real-time  display  of  MIL-STD-2525B 
symbology.  MIL-STD-2525B  specifies  graphical  templates  for  each  of  the  symbols.  The 
standard  provides  a  different  template  for  each  symbol.  We  classify  each  template  into  one  of 
ten  categories  (detailed  in  the  appendix.) 

While  many  systems  use  the  individual  symbol  templates  explicitly  for  both  symbol  creation  and 
manipulation,  there  may  be  efficiency  gains  if  these  template  categories  are  superimposed  on 
appropriately  attributed11  free-hand  drawings  and  the  defining  points  are  extracted 
algorithmically.  In  this  system,  users  select  the  type  of  symbol  they  want  to  create  from  a 


10  Who  wants  to  (or  should)  tether  to  whom,  who  wants  to  (or  should)  share  sketches  or  other  attentional  ink  or  graphical 
annotation  with  whom. 

1 1  Namely  with  the  MIL-STD-2525B  symbol  identification  code. 
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graphical  palette  of  recently  or  frequently  used  symbols.12  They  are  then  prompted  to  draw  the 
appropriate  category  (draw  a  U  for  a  U-shaped  template  category,  draw  a  J  for  a  J-shaped 
category,  etc.).  Once  this  has  been  done,  they  draw  the  location  and  basic  shape  for  the  category. 
The  defining  points  for  the  template  category  are  then  extracted,  and  a  new  symbol  is  added  to 
the  user’s  map  and  sent  to  the  TOS  for  dissemination  to  others.  The  real-time  rendering  of 
symbology  is  implemented  by  double-buffering  the  map  display  generated  by  ArcMap  and 
sending  the  bitmap  and  associated  geographic  coordinates  to  TRW’s  Graphical  Symbology 
Display  library  to  render  the  symbols. 

The  collaboration  component  supports  user-to-user  collaboration  through  the  Collaboration 
Server.  Users  can  share  sketches  and  other  graphical  annotations,  tether  map  displays,  chat  and 
send  files  via  this  interface.  When  sharing  sketches,  the  client-side  application  renders  each  line 
segment  as  it  is  received  instead  of  waiting  until  the  entire  sketch  has  arrived.  This  effectively 
captures  the  temporal  aspect  associated  with  the  creation  of  the  sketch  allowing  users  to  convey  a 
sense  of  urgency  to  their  annotations.  Figure  6  shows  an  example  of  the  tethering  and  sketch 
sharing  UI  with  some  explanatory  notations.  Figure  7  shows  an  example  of  the  chat  and  file 
sharing  UI. 
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Or  using  a  dictionary  indexed  along  a  variety  of  dimensions  including  lexically  and  hierarchically. 
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Figure  7.  Collaborative  map  tethering  and  doodling  -  File/Chat  Sharing. 


The  sensor  coverage  component  is  used  to  display  range  fans,  lines  of  bearing,  directional 
arrows,  and  other  detection  indicators  to  illustrate  sensor  coverage  and  activity.  Examples  of 
these  capabilities  are  shown  in  figure  8. 

In  the  upper  center  portion  of  this  the  range  fans  of  two  cameras  mounted  on  a  building  roof  are 
displayed.  The  coverage  than  can  be  achieved  by  these  cameras  is  reported  by  the  camera  rather 
than  being  “made  up”  by  the  display  program.  As  a  consequence,  the  map  display  has  the  ability 
to  display  “true”  information  which  may  be  used  by  the  operator  for  planning  purposes.  Note 
from  the  figure  that  the  upper  two  cameras  (looking  Northward)  have  overlapping  fields  of  view. 
In  situations  such  as  this,  it  is  possible  to  transfer  use  of  one  camera  to  another  as  an  object  of 
interest  moves  from  the  view  of  one  camera  to  the  view  of  both  cameras  to  the  view  of  the  other 
camera. 

Also  shown  in  figure  8  is  an  infrared  tripwire  sensor.  This  sensor  is  the  yellow  symbol  just  to  the 
right  and  below  the  center  of  the  figure.  The  field  of  view  of  this  sensor  is  shown  in  a  manner 
that  is  identical  to  the  field  of  view  display  for  the  camera.  That  is,  the  field  of  view  is  reported 
by  the  sensor  it  self.  This  particular  tripwire  sensor  also  reports  the  line  of  bearing  of  objects  that 
cause  it  to  trip.  The  red  line  that  runs  up  center  of  the  field  of  view  of  the  tripwire  sensor  is  such 
a  report. 
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Figure  8.  Sensor  coverage  and  detection. 

As  the  sensors  themselves  are  actually  reporting  their  characteristics,  the  map  display  can  be  a 
very  useful  tool  in  planning  the  location  of  sensors  and  a  very  useful  tool  for  analyzing  targets  as 
they  move  through  fields  of  sensors.  It  is  also  true  that  since  the  sensors  report  their  own 
characteristics,  there  is  a  potential  to  automate  much  of  the  processing  that  might  be  done  by  a 
human  using  the  map  display  as  an  analysis  tool. 

2.4  Future  Work,  The  Map  Display 

Digital  Ink  is  currently  integrated  with  ESRI’s  ArcMap  application  as  an  ArcMap  extension.  We 
decided  to  plug  into  ArcMap  instead  of  using  ESRI’s  ArcEngine  as  a  library  underneath  an  ARL 
application  because  INSCOM  Intelligence  Analysts  were  already  familiar  and  comfortable  with 
ArcMap.  With  the  award  of  the  Commercial  Joint  Mapping  Toolkit  (C/JMTK)  contract,  a  DoD- 
wide  license  has  been  created  for  the  development  of  C2  systems.  The  ArcEngine  and  associated 
developer  kit  are  included  in  the  license  agreement,  but  the  ArcMap  Desktop  application  is  not. 
Our  current  efforts  include  re-implementing  Digital  Ink  as  a  standalone  application  using 
ArcEngine.  Additionally,  TRW’s  Graphical  Symbology  Display  is  no  longer  supported,  so  we 
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are  replacing  the  rendering  of  symbology  with  ESRI’s  Military  Overlay  Editor,  which  is  part  of 
the  C/JMTK. 


3.  UGS  Integration 


3.1  The  UGS 

ARL  integrated  four  operational  and  two  experimental  UGS  systems  into  the  C4ISR  OTM 
experiment.  Three  of  the  operational  systems  were  developed  for  the  Army  and  one  was 
developed  for  the  United  States  Marine  Corps  (USMC).  The  Army  UGS  included  one 
OmniSense  system  provided  by  McQ  Inc.,  one  Scorpion  system  provided  by  Northrop 
Grumman,  and  one  Silent  Watch  system  provided  by  Harris.  The  USMC  UGS  consisted  of  one 
Tactical  Remote  Sensor  System  (TRSS).  All  four  sensor  systems  contained  at  least  one  imager. 
To  minimize  power  consumption,  the  imagers  and  associated  processors  typically  remain  in  a 
low  power  state  until  cued  by  activity  sensors.  The  activity  sensors  on  all  four  operational 
systems  are  capable  of  detecting  both  vehicles  and  personnel  in  the  vicinity.  The  OmniSense 
system  employed  in  the  experiment  consisted  of  visible  and  thermal  imagers  cued  by  seismic, 
acoustic,  and  passive  infrared  (PIR)  activity  sensors.  The  Scorpion  system  contained  both 
visible  and  thennal  imagers  cued  by  magnetic  and  seismic  activity  sensors.  The  Silent  Watch 
system  contained  a  low  light  visible  imager  and  an  thermal  imager  cued  by  seismic  and  PIR 
activity  sensors.  The  TRSS  contained  visible  and  thennal  imagers  cued  by  activity  sensors 
which  can  be  configured  to  use  acoustic,  seismic,  or  PIR  transducers. 

ARL  also  integrated  two  internally  developed  experimental  sensor  systems:  a  MMS  system  and  a 
Tripwire  Camera  (TWC).  The  MMS  is  a  very  low-cost  non-imaging  system  consisting  of  a 
number  of  single-package  seismic,  acoustic,  and  PIR  transducers.  Depending  on  the  desired  or 
observed  specificity  and  sensitivity  during  operations,  the  MMS  can  be  configured  to  generate 
activity  reports  only  when  certain  combinations  of  the  three  sensors  are  activated.  The  MMS 
does  not  provide  localization  and  only  reports  that  activity  is  occurring  in  its  proximity.  One 
MMS  sensor  suite,  consisting  of  six  sensors  and  a  gateway  node,  was  employed  during  the 
experiment.  The  TWC  consists  of  an  off-the-shelf  low-cost  daytime  color  imager  commonly 
used  in  cell  phones  cued  by  a  PIR  motion  detector.  The  camera  remains  idle  until  the  PIR 
detector  activates  it  in  response  to  motion  in  its  field  of  view.  After  image  capture,  the  image 
and  direction  of  motion  are  packaged  into  a  sensor  report  for  delivery  back  to  the  UGS/UGV- 
SRW  gateway  HMMWV.  Two  TWCs  were  employed  during  the  experiment. 

3.2  The  UGS  Communications 

While  each  UGS  comes  with  its  own  communications  system,  ARL  is  promoting  the  idea  of 
common  communications  protocols  and  devices  as  part  of  its  Family  of  UGS  concept.  As  ARL 
has  not  yet  identified  a  suitable  standard  protocol  and  the  developers  of  three  of  the  four 


16 


operational  systems  already  had  some  experience  with  McQ  Inc.’s  Common  Data  Interchange 
Format  (CDIF),  for  the  sake  of  expedience  CDIF  was  chosen  as  the  common  communications 
protocol  for  this  experiment.  ARL’s  Blue  Radio  was  used  as  the  common  communications 
device.  The  Blue  Radio  provides  secure  long  range  data  communications  in  the  tactical  ultra 
high  frequency  (UHF)  frequency  band.  Battery  life  is  maximized  by  intelligently  managing  the 
transmitter  and  receiver  power  of  the  radio.  Multiple  radios  will  discover  each  other  and  form  an 
ad  hoc  network  amongst  themselves.  Although  direct  communications  between  any  two  radios 
is  possible,  in  practice  one  or  more  radios  is  configured  to  be  a  gateway  or  sink  which  every 
other  radio  will  establish  a  route  to. 

For  C4ISR  OTM,  a  Blue  Radio  was  mounted  in  the  UGS/UGV-SRW  gateway  HMMWV  and 
configured  as  the  only  gateway  in  the  Blue  Radio  network.  Since  OmniSense  already  used  the 
CDIF  protocol,  the  only  change  required  to  integrate  it  into  the  experiment  was  to  replace  its 
communications  device  with  the  Blue  Radio.  For  the  Scorpion  and  Silent  Watch  sensors,  a 
separate  laptop  computer  was  used  to  bridge  between  them  and  the  Blue  Radio  network.  Since 
these  systems  already  used  serial  radios  for  their  native  communications,  the  original  radio  was 
simply  removed  and  replaced  by  the  laptop/Blue  Radio  equipment.  The  radio  plugged  into  a 
second  serial  port  on  the  laptop.  Additionally,  Scorpion  and  Silent  Watch  used  the  laptop  to 
translate  from  their  native  protocol  into  CDIF  just  prior  to  transmission  over  the  Blue  Radio. 
There  was  insufficient  time  to  translate  the  TRSS  native  protocol  into  CDIF;  the  Blue  Radio  was 
already  integrated  with  its  imager’s  processor.  As  a  result,  no  laptop  was  necessary,  but  special 
TRSS  message  handlers  had  to  be  installed  on  the  UGS/UGV-SRW  gateway  HMMWV.  The 
TWC  and  MMS  were  designed  to  use  the  Blue  Radio  natively  so  no  laptop  or  other 
communications  bridge  was  necessary.  However,  there  was  insufficient  time  to  develop  the 
software  to  translate  their  native  protocols  into  CDIF  so  special  handlers  were  installed  on  the 
gateway  similar  to  the  TRSS.  Figure  9  shows  the  deployment  of  relevant  components  used 
during  the  experiment  from  the  perspective  of  the  UGS. 
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Figure  9.  UGS  integration  architecture. 
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4.  Unmanned  Vehicles 


4.1  Unmanned  Ground  Vehicles 

ARL  integrated  three  iRobot  PackBot  Explorers  into  the  experiment.  The  PackBots  were 
equipped  with  a  communications  payload  developed  by  ARL  and  IHMC.  This  payload  consisted 
of  a  Linksys  802. 1  lg  wireless  router  running  OpenWRT  Whiterussian  custom  firmware  and  an 
open  source  Optimized  Link  State  Routing  (OLSR)  routing  daemon.  In  addition  to  the  custom 
payloads,  ARL  developed  its  own  OCU  software.  This  software  was  installed  on  ruggedized 
Itronix  Duo-Touch  Windows  XP  Tablet  PCs  that  had  been  modified  to  use  Army  standard  BB- 
2590  compatible  batteries.  Communications  were  provided  by  the  same  type  of  Linksys  router 
used  on  the  PackBot  communications  payload.  The  OCU  was  equipped  with  dual  CH  Products 
industrial  joysticks  mounted  on  a  frame  bolted  to  the  tablet  PC.  Three  OCUs  were  used  during 
the  experiment.  Ligure  10  shows  the  OCU  hardware.  The  Linksys  router  is  mounted  underneath 
the  tablet. 


Figure  10.  ARL  OCU  hardware. 

A  communications  payload  similar  to  that  on  the  PackBot  was  mounted  on  the  UGS/UGV-SRW 
gateway  HMMWV.  UGV  and  OCU  data  were  routed  to  the  TOS  for  dissemination  to  other 
OCUs  (for  SA),  to  higher  echelons  via  WIN-T,  and  to  other  local  HMMWVs  via  SRW.  The 
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software  components  and  data  flow  for  these  activities  is  described  in  more  detail  in  a  later 
section.  Figure  1 1  shows  the  asset  deployment  and  communications  links  from  the  UGV 
perspective. 


Figure  11.  UGV  integration  (communications). 


In  addition  to  the  new  payload,  ARL  installed  video,  control,  telemetry,  and  middleware 
software  on  the  main  PackBot  processor.  ARL’s  control  and  telemetry  software  uses  the  iRobot 
Aware  1 .2  Robot  Intelligence  Software  to  control  the  PackBot  and  acquire  positional  and  other 
telemetry  data.  The  video  software  replaces  the  iRobot  video  server  and  supports  sending  either 
MPEG-4  or  Motion  JPEG  video  streams  to  an  arbitrary  number  of  clients  at  user-selectable 
frame  rates,  resolutions,  and  compression  levels.  The  control  software  supports  both  low-level 
(e.g.,  move  forward  at  1  m/s)  and  mission-level  (e.g.,  navigate  to  these  waypoints)  commands. 
Both  the  video  and  control  software  advertise  their  services  through  the  distributed  discovery 
mechanisms  provided  by  the  ACM. 

The  OCU  software  consisted  of  the  Digital  Ink  map  display  described  earlier  which  provided  SA 
for  the  PackBots’  positions  and  all  other  global  positioning  system  (GPS)-equipped  assets  in  the 
experiment  combined  with  a  C2  application  which  allowed  the  operators  to  control  and  monitor 
any  of  the  robotic  assets.  Operators  have  the  ability  to  capture  and  annotate  individual  images 
from  any  of  the  video  feeds  and  submit  them  to  higher  echelons.  Any  OCU  can  be  used  to 
control  any  robotic  asset.  Operator  contention  is  handled  by  locking  out  other  operators  once  an 
OCU  has  control.  The  current  availability  status  of  the  robot  is  indicated  on  the  display.  A 
commandeer  capability  exists  allowing  an  operator  to  override  this  lockout  in  an  emergency  or 
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exceptional  situation.  The  OCU  software  uses  the  distributed  discovery  services  provided  by  the 
ACM  to  discover  the  available  robotic  assets.  Figure  12  shows  an  image  of  the  OCU  control 
software. 


burease/Decrease 
Frame  Rate 


Figure  12.  ARL  UGV  OCU  C2  application. 

4.2  Micro  Air  Vehicles 

ARL  partially  integrated  the  Nighthawk  MAV  developed  by  Applied  Research  Associates  into 
the  C4ISR  OTM  experiment.  The  Nighthawk  is  a  man-portable,  hand-launched  unmanned  air 
vehicle  capable  of  autonomous  flight  using  an  integrated  GPS  and  autopilot.  The  vehicle  is 
equipped  with  multiple  video  cameras.  The  Nighthawk  system  is  comprised  of  the  MAV  itself,  a 
laptop-based  control  station,  and  a  remote  video  receiver.  The  control  station  uses  the 
FalconView  mapping  system  for  MAV  tasking  and  SA. 
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ARL  injected  the  MAV  telemetry  data  into  C4ISR  OTM  by  connecting  a  gateway  laptop  to  a 
serial  port  on  the  control  station  laptop  that  was  configured  to  stream  NMEA  0183-like  telemetry 
data.  This  data  was  sent  to  the  TOS  for  further  dissemination.  The  remote  video  tenninal 
received  wide-band  NTSC  analog  video  over  a  2.4GHz  link.  The  NTSC-Out  port  of  the  remote 
video  receiver  was  connected  to  a  USB  frame  grabber  on  the  gateway  laptop  and  exposed  the 
video  feed  to  remote  systems  in  the  same  manner  as  that  described  for  the  UGVs.  Figure  13 
shows  the  deployment  of  relevant  components  used  during  the  experiment  from  the  perspective 
of  the  MAV  integration. 


Figure  13.  MAV  integration  architecture. 

4.3  Future  Work 

As  part  of  the  Family  of  UGS  concept,  ARL  is  investigating  the  use  of  cross-asset  tipping  and 
cueing  between  UGS,  UGVs,  and  MAVs.  For  example,  an  UGS  field  may  exhibit  enough 
interesting  activity  to  warrant  further  investigation.  This  further  investigation  could  be  carried 
out  autonomously  by  UGVs  or  MAVs  if  the  assets  could  be  automatically  tasked.  Initially,  we 
plan  to  generate  waypoints  and  missions  based  on  UGS  and  UGV  reports  and  task  the 
Nighthawk  MAV  using  STANAG  4586  messages  sent  to  a  socket-based  server  running  on  the 
Nighthawk  control  station. 
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Appendix:  MIL-STD-2525B  Symbol  Classification 


1)  Point  templates  have  a  single  anchor  point, 


2)  Area  templates  use  all  of  the  input  points, 


— *  s 

y 

l  -m  ) 

i  EA  1  T  | 

CHqectrve 

Attadk  Position 

Engagement  Area. 

3)  Line  templates 


a.  Unsampled  line  templates  use  all  of  the  input  points  with  the  start  and  end  points 
designated  as  anchor  points, 


7 


- 1  t  i  Ai*-i  q  i 

I  PI  3  ' 


Phase  Line 


No  Fire  Line 


Line  of  Departure 


b.  2 -point  line  templates  use  only  the  start  and  end  points, 


FixTaA  Ferry  Crossing  Follow  and  Sappoct 


^-WWW^ 

'  PT  2  _  .  ' 


4)  Arrow  templates  use  the  start  point,  the  tip  of  the  arrow  head,  and  the  location  of  one  of  the 
arrow  head  end  points  as  anchor  points, 


...  ^ 

"‘A 

r — 

PT  2 

=£> 

Axis  of  Advance 

Main  Attach: 

5)  Circle  templates  use  the  start  point  and  the  center  point  as  anchor  points, 
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6)  V-shaped  templates  use  the  base  point  of  the  V  and  the  2  top  end  points  as  anchor  points, 


7)  L-shaped  templates  use  the  start  point,  bend  point,  and  end  point  as  anchor  points, 


- 

Disrupt  Task 

8)  J-shaped  templates  use  the  start  point,  bend  start  point,  and  end  point  as  anchor  points, 


WT  J  - 

^ - 

PT  ]  - - 

[^]  j 

.. 

if  ) 

'pti  ' 

t - TTT' 

Retirement  Task: 

Withdraw  'lask 

DeliyTisk 

9)  T-shaped  templates  use  the  two  top  end  points  and  base  point  as  anchor  points, 


PT.  1 - - 

PT-  3 

PT.3 

/ 

PT.  2  _ _ 

Block.  Task. 

fpT.I  PT.2  ^ 

Ford  -  Easy 

10)  U-shaped  templates 

a.  3-point  U-shaped  templates  use  the  two  top  end  points  and  the  mid-point  of  the  base  as 
anchor  points, 
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Breach  TaA  Difficnlt  Obstade  Bypass 


b.  4-point  U-shaped  templates  use  the  two  top  end  points  and  two  base  points  as  anchor 
points, 


25 


5.  References 


1 .  Press  Release,  CERDEC,  PM  C4ISR  OTM  Office,  20  June  2007 

2.  Suri,  Niranjan;  Bradshaw,  Jeffrey  M.;  Carvalho,  Marco  M.;  Cowin,  Thomas  B.;  Breedy, 
Maggie  R.;  Groth,  Paul  T.;  Saavedra,  Raul.  Agile  Computing:  Bridging  the  Gap  between 
Grid  Computing  and  Ad-hoc  Peer-to-Peer  Resource  Sharing.  Proceedings  of  the  3rd 
IEEE/ACM  International  Symposium  on  Cluster  Computing  and  the  Grid  (CCGrid  2003), 
(May  2003),  pp.  618-625. 

3.  Suri,  N.;  Rebeschini,  M.;  Arguedas,  M.;  Carvalho,  M.;  Stabellini,  S.;  Breedy,  M.  Towards 
an  Agile  Computing  Approach  to  Dynamic  and  Adaptive  Service-Oriented  Architectures.  In 
Proceedings  of  the  First  IEEE  Workshop  on  Autonomic  Communication  and  Network 
Management  (ACNM'07). 

4.  Suri,  N.;  Rebeschini,  M.;  Breedy,  M.;  Carvalho,  M.;  Arguedas,  M.  Resource  and  Service 
Discovery  in  Wireless  Ad-Hoc  Networks  with  Agile  Computing.  In  Proceedings  of  the  2006 
IEEE  Military  Communications  Conference  (MILCOM  2006),  Washington,  D.C.,  October 
2006. 

5.  Carvalho,  M.;  Suri,  N.;  Arguedas,  M.  Mobile  Agent-based  Communications  Middleware  for 
Data  Streaming  in  the  Battlefield.  In  Proceedings  of  the  2005  IEEE  Military 
Communications  Conference  (MILCOM  2005),  Atlantic  City,  New  Jersey,  October  2005. 


26 


Acronyms 


ACM 

Agile  Computing  Middleware 

ARL 

Army  Research  Laboratory 

C/JMTK 

Commercial  Joint  Mapping  Toolkit 

C2 

Command  and  Control 

C4ISR  OTM 

Command,  Control,  Computers,  Communications,  Intelligence, 
Surveillance,  and  Reconnaissance  On-the-Move 

CDIF 

Common  Data  Interchange  Fonnat 

CERDEC 

Army  Communications,  Electronics  Research,  Development,  and 
Engineering  Center 

CIMS 

C4ISR  Infonnation  Management  Service 

DoD 

Department  of  Defense 

FBCB2 

Force  XXI  Battle  Command,  Brigade-and-Below 

FCS 

Army  Future  Combat  Systems 

GPS 

Global  Positioning  System 

HMMWV 

High  Mobility  Multipurpose  Wheeled  Vehicle 

IHMC 

Institute  for  Human  and  Machine  Cognition 

INSCOM 

Army  Intelligence  and  Security  Command 

IP 

Internet  Protocol 

MANET 

Mobile  Ad-Hoc  Network 

MAV 

Micro  Air  Vehicle 

MIL-STD-2525B 

Department  of  Defense  Common  Warfighting  Symbology  Standard 

MMS 

Multi  Modal  Sensor 

OCU 

Operator  Control  Unit 

OLSR 

Optimized  Link  State  Routing 

OSI 

Open  Systems  Interconnection 
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P2P 

Peer  to  Peer 

PIR 

Passive  Infrared 

QoS 

Quality  of  Service 

SA 

Situational  Awareness 

SLICE 

Soldier-Level  Integrated  Communications  Environment 

SOS 

Sensed  Object  Server 

SRW 

Soldier  Radio  Waveform 

TCP 

Transmission  Control  Protocol 

TOS 

Tactical  Object  Server 

TRSS 

Tactical  Remote  Sensor  System 

TWC 

Tripwire  Camera 

UDP 

User  Datagram  Protocol 

UGS 

Unattended  Ground  Sensor 

UGV 

Unmanned  Ground  Vehicle 

UHF 

Ultra  High  Frequency 

UI 

User  Interface 

USMC 

United  States  Marine  Corps 

WIN-T 

Warfighter  Information  Network-Tactical 

XML 

Extensible  Markup  Language 
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